Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-038.txt

Text File | 1992-11-18 | 46.7 KB | 1,255 lines | [TEXT/MPS ]

C.S.M.P. Digest             Mon, 30 Mar 92       Volume 1 : Issue 38

Today's Topics:

     Userland's Frontier anyone?
    SetLineWidth PicComment (followup and query)
    lexical database available
     Finding out who I am on AppleTalk
    DEVELOP - which issue are we up to ?
    ppmtopict and macvert
    TC5.0 and Colortoolbox


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Malcolm Pradhan)
Subject:  Userland's Frontier anyone?
Date: 29 Feb 92 00:03:13 GMT
Organization: Faculty of Medicine, University of Adelaide

In article <[e-mail]> [e-mail]
(Mister Rogers) writes:
> I recently got a mailing from Userland Software, Inc. regarding
> their new, much anticipated program "Frontier". I know Frontier
> has generated a lot of press in the Mac-kingdom and on the net,
> and I'm curious as to what this program really is.

 I purchased Frontier at the MacWorld Expo, I've been waiting for a
scripting language for some time. I use Frontier for a number of tasks
but I haven't had time to do a rigorous examination of it eg. bench-
marks.

 Frontier is a full scripting language for the Mac, it is very
extensible and takes advantage of AppleEvents to allow scripting
of AppleEvent (AE) savvy applications. Basically it the Frontier
language (UserTalk) is a rather nice mixture between C, Pascal
and HyperTalk.

 The environment is built around an "object database" - a
heirarchical structure which can store UserTalk scripts, plain or
formatted text, numbers, strings etc., tables or binary data.
You can easily create new items in tables or whole tables to
store values, scripts or miscellaneous data grabbed via AEs from
other applications.

 It has all the usual operators: +,-,*,/,=,== (equality),! (not),
++ (increment), --, && (and), || (or), ^, % (mod) as well as <, >=
etc. It also uses @ for pointers to scripts and objects in the
object database, and it can treat tables like arrays using [].

 Control Structures: break, case..else, continue, fileloop..in
(for sequentially getting all the files/folders in a directory),
for..to, if..else, loop, on, return, while.

 The editor is very interesting, it is based on an outliner (Dave
Winer founded UserLand), so it is easy to collapse and expand
bits of code to make things readable. I've found this works very
well indeed.

 Verbs: UserTalk is based on command 'verbs'. These verbs are
usually grouped into suites. For example there is a Finder suite
of verbs which can change views, open or close windows, set icon
positions, alias, drag, duplicate, empty trash, shut down etc.
The verbs are actually UserTalk functions which call a built-in
"appleevent" primitive to translate the high level UserTalk
command into a lower level AE call to the Finder, thereby insulating
the scripter from the headaches of building AE descriptors, etc.
This means when an AE savvy application comes out, someone
(preferably the author of the program), can create a suite of
UserTalk verbs to access the AE features of the program. Apps which
make lots of use of AEs won't need to provide macros or scripting
as Frontier could easily control it.

 Frontier comes wit lots of suites - many file verbs (copy, delete,
create file/folder, move, rename, set creator/type/creator& mod
dates, count lines, compare, size, read, write, get lots of file
and disk info, lock/unlock, alias etc.etc. There are also launch,
keyboard, clock, menu, mouse, outline processing, word processing
(for its own built in wp), search, string, table, window, menu and
dialog verbs. Basically you can do quite a bit with it. There are
also the low level verbs which you can use to build high level
verbs for applications.

 There is also a unix cron-like feature called "agents", these handy
giblits can be set to run at particular times, or periodically eg.
for backing up, tidying up hard disks of networked macs, sending
mail.

 I like Frontier a lot. It takes about 1Mb RAM, comes with
online documentation via an AE aware "DocServer", its speed seems
reasonable for an interpreted language (actually compiled to byte-
codes) and so far it seems pretty stable. I haven't pushed it though.
It's hard to complain about the interface - the outline processor is
very nice, you can change the menus and command keys very easily (they
are stored as outlines, hierarchical menus are just another level
in the outline - elegant). I wish I could keep it running all the time
but I can't spare the 1Mb during some tasks.

 Although Frontier is very useful for file system scripting out of the
box, the ultimate success of Frontier depends on how many programs
support AEs and to what extent. The greater the support of AEs, the
more use Frontier is. I'm not sure how it will stack up against
AppleScript when it arrives (?next year), but Frontier is here now
and it's pretty powerful. I hope that the big programs support and
publish AE so we can get to do some really clever things which go
far beyond batch files and even pipes.


 Regards,
 Malcolm

 "Any place that needs disclaimers has too many lawyers"

_________________________________________________________________
    Malcolm Pradhan
    Medical Computing, Faculty of Medicine         _--_|\
    University of Adelaide, South Australia       /      \
    InterNet: [e-mail]   \_.--x_/
    Fax: [phone]  :x marks the spot:              v



---------------------------

From: [e-mail] (David Maddison)
Subject: SetLineWidth PicComment (followup and query)
Date: 27 Feb 92 15:52:04 GMT
Organization: Harvard University Science Center


Thanks very much to those who answered my query about how to undo
the SetLineWidth PicComment for postscript laserwriters.
A solution is illustrated in the following bit of code:

       PenSize(1, 1);
       MoveTo(100, 100);
       SetLineWidth(1, 4);
       Line(0, 200);        {this line is a hairline}
       SetLineWidth(4, 1);
       SetLineWidth(1, 1);
       Line(200, 0);        {this line is 1 pt}

However, it is clear that the behavior is not as simple as described
in the responses: the setlinewidth does not simply set a line
scaling factor which can only be undone by a compensatory
setlinewidth call.  For if that were the case, then in the following
code:

       PenSize(1, 1);
       MoveTo(100, 100);
       SetLineWidth(1, 4);
       Line(0, 200);        {this line is a hairline}
       SetLineWidth(1, 1);
       PenSize(2, 2);
       Line(0, 10);        {this line is printed as 2 pt}
       PenSize(1, 1);
       Line(200, 0);        {this line is printed as 1 pt}


the last two Lines should produce 1/2 and 1/4 pt lines, as no
compensatory SetLineWidth(4,1) call is made, and as the
SetLineWidth(1,1) is purportedly ignored on a postscript
laserwriter.  It seems that a SetLineWidth(1,1) call, changing the
pensize temporarily, drawing a line, then changing the pensize back
has the same effect as a compensatory SetLineWidth(4,1) call.  Note
that if either of the two lines

       PenSize(2, 2);
       Line(0, 10);

are removed, then the last line is drawn as a
hairline.  Why this temporary PenSize change kicks the driver into
removing the scaling factor I don't know.

Anyone have any explanation for this behavior of the SetLineWidth
PicComment?


David Maddison
[e-mail]



---------------------------

From: [e-mail] (Grady Ward  [e-mail])
Subject: lexical database available
Date: 27 Feb 92 14:06:58 GMT
Organization: BTR Public Access UNIX, MtnView CA. Contact: Customer Service [e-mail]

Apple's recent announcement of a 100,000
word vocabulary speech recognition technology
underscores the recent flurry of activity in
English-language-aware engineering.

Since there are so few (virtually no) lexical
resources as the following, I will post it twice
a year so that you may be aware of it.

- -

If you are developing am application that needs to
interact with users in English, then you will want
to be aware of the Moby library of lexical databases,
available in source ASCII, that you can include into
you research projects or commercial application
royalty-free.  There are five databases publicly available:

Moby Words -- 560,000 English language entries
(applications: spelling checkers, password screening,
password generation, word recreations, compression modeling)

Moby Hyphenator -- 155,000 fully hyphenated entries
(applications: correctly formatted textual output,
music lyric syllabification)

Moby Part-of-Speech -- 214,000 entries marked with
up to seventeen part(s)-of-speech in English, in order of use.
(applications: input parsing, principle or rule-based grammars,
generation of syntactically-correct English)

Moby Pronunciator -- 167,000 entries with full International
Phonetic Alphabet encoding, including syllabification and
primary, secondary, and tertiary stress marks.  Hundreds
of same spelling/different part-of-speech and pronunciation
disambiguated.
(applications: text-to-speech drivers for multimedia,
continuous speech recognition models (such as Apple's
newly announced system), rhyming dictionaries,
pronounceable password generation)

Moby Thesaurus -- 1.2 million synonyms and related ideas
(applications: concept-driven database searches, free-form
English language input parsing [such as that required for
Loebner Prize contestants], on-line thesauruses,
universal parsing machines, generative semantics,
non-literal parsings.)

These databases are intended to free the developer or
researcher from the tedium of attempting to collect similar data sets.
We have aimed at comprehensiveness; we have found that it is _much_
easier to edit or delete rather than compile this data in the first place.
_Save your time for the creative aspects of your application_

All databases are supplied in pure ASCII, royalty-free, in
both Macintosh and MS-DOS disk formats (also in .Z file
formats) Both commercial (to resell derived structures as
part of commercial applications) and educational/research
licenses are available.

For a FREE BROCHURE with sample entries and details on
getting your own copy of this material, write or telephone
your postal address:

Illumind Unabridged
Grady Ward, compiler
571 Belden St., Ste. A.
Monterey, CA  93940
USA
[phone]
Internet: [e-mail]

--
Grady Ward  [e-mail]  KD6ETH @ K6LY.#NOCAL.CA.USA.NA  Moby Lexicons



---------------------------

From: [e-mail] (Michael Peirce)
Subject:  Finding out who I am on AppleTalk
Date: 30 Jan 92 23:15:01 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (WILLIAM D. BURNS) writes:
> Greetings all,
>   I am attempting to write an application for a mac lab I work at and
> bascially I need to find out what the user name is that the user logged onto
> the AppleShare server with.  I can't seem to find any clear cut info on this
> stuff in the IM's vols. 1-5.  Am I missing something here?
>
> Also, I will eventually need to set this username into the Chooser's name
> field so that we can know who to charge for printer usage (using AppleShare's
> Print server thing).
>
> I'm working primarily in Think C but any code/suggestions would be helpful!

The "chooser name" is stored in string resource with ID = -16096.  You
can grab it with the following line of code:

    chooserNameHandle = GetString(-16096);

where chooserNameHandle is a handle to the (pascal style) string.

The above was true before System 7, and still is to a certain extent.

With System 7 their are now two name strings: the owner name and the Macintosh
name.  String -16096 is now used to identify the Mac and a new string,
ID = -16413, is use used to identify the user.

Typical usage would be owner name = "Michael Peirce"
                   Macintosh name = "Michael's Mac Plus"

System 7 Filesharing uses the name of the Machine as the name of the
server and uses the owner name as the default login name when you
connect TO a server.

Keep in mind that user doesn't HAVE to log in to an AppleShare server
using their default name.  It's easy for them to type in something
else as they are mounting the volume.

I guess if you really need to set these strings you can simply update
the appropriate string resources in the system file.  I'd think twice
before doing this, since some users may frown on you modifying the
system file behind there back.

--  Michael Peirce         --   [e-mail]
--  Peirce Software        --   Suite 301, 719 Hibiscus Place
--  Macintosh Programming  --   San Jose, California USA 95117
--           & Consulting  --   voice: [phone] fax: [phone]
--                         --   AppleLink: peirce & America Online: AFC Peirce



---------------------------

From: [e-mail] (Michael Graf)
Subject: DEVELOP - which issue are we up to ?
Date: 27 Feb 92 19:33:08 GMT
Organization: Australian Programming Centre (IBMA)


    Can someone please let me know what the most recent version of DEVELOP
   (the CD-ROM/Magazine from APDA/AAPDA) is ? I have not received a copy of
   DEVELOP since I renewed my AAPDA membership last November and am wondering
   whether there has been a release since then.

     Many thanx, in advance, for the information.


**********************************************************************
Regards,
  Michael Graf                             ([e-mail])
**********************************************************************



- -------------------------

From: [e-mail] (Donald T. Major)
Subject:  DEVELOP - which issue are we up to ?
Date: 27 Feb 92 19:50:41 GMT
Organization: SAS Institute Inc.

Number 9 is due out anytime now (my more fortunate friends have received
their developer series CD-ROMs this week, with the electronic form of
the issue).  If it follows the usual delay between developer CD-ROM
and magazine/CD-ROM appearance, it should arrive within the next week.

                                             ..
                                            dtm
--
Donald Major       SAS Institute Inc.  "Cicely, let's fling something!"
[e-mail] SAS Campus Drive                 - Northern Exposure
[phone]     Cary, NC 27513-2414



- -------------------------

From: [e-mail] (Brad Kollmyer)
Subject:  DEVELOP - which issue are we up to ?
Date: Fri, 28 Feb 92 19:49:06 PDT
Organization: Vital Consulting


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Donald T. Major) writes:
> Number 9 is due out anytime now (my more fortunate friends have received
> their developer series CD-ROMs this week, with the electronic form of
> the issue).  If it follows the usual delay between developer CD-ROM
> and magazine/CD-ROM appearance, it should arrive within the next week.

I received mine last week.

Brad Kollmyer.
[e-mail]




---------------------------

From: [e-mail] (Ray Johnson)
Subject: ppmtopict and macvert
Date: 27 Feb 92 20:30:27 GMT
Organization: Georgia Institute of Technology


Does anyone out there use the UNIX utils ppmtopict and macvert.
I'm trying to get some images to the Mac for use in a help system.
However, the docs for the two utils aren't very clear on how to
convert the pict data created by ppmtopict (which is just data
and is not in MacBinary format) into something that the Mac can
understand.

- ----------------------------------------------------------------------------
Raymond W. Johnson
Graphics, Visualization, and Usability Center
College of Computing
Georgia Institute of Technology
801 Atlantic Drive                                       [phone] (Work)
Atlanta, GA 30332-0280                                   [phone] (Home)
- ----------------------------------------------------------------------------



- -------------------------

From: [e-mail] (Burkhard Neidecker-Lutz)
Subject:  ppmtopict and macvert
Organization: CEC Karlsruhe
Date: Fri, 28 Feb 92 08:54:04 GMT


I tried to use macvert 1.65 and it didn't do anything useful for me.
I ended up writing a program myself which writes a MacBinary header
(simple because I found doc on that) and a resource fork (hard because
I couldn't find any doc) by (gasp) getting binary dumps of a valid
MacBinary header and resource fork of a PICT file and glueing the
output of ppmtopict (which creates a valid data fork) in between
(patching up the parts of the MacBinary header). An abomination
but works. If you're interested I can provide you the source and
maybe somebody with more understanding of Mac's can help to eventually
change this to something less horrible.



        Burkhard Neidecker-Lutz

Multimedia Engineering, CEC Karlsruhe
Software Motion Pictures
Digital Equipment Corporation
[e-mail]



- -------------------------

From: [e-mail] (Fred Walsteijn)
Subject:  ppmtopict and macvert
Date: 29 Feb 92 10:38:57 GMT
Organization: Physics Department, University of Utrecht,  The Netherlands

It's very simple actually: the output from ppmtopict can be transferred
in ordinary binary mode (not macbinary) to your Mac.
There the pict file can be read if you change its filetype to "PICT"
(using DeskZap, or ResEdit, or...), or if you have PhotoShop: use
the "Open As" menuitem (and select "Pict File").

Greetings,
- ----------------------------------------------------------------------------
Fred Walsteijn                                |  Internet: [e-mail]
Institute for Marine and Atmospheric Research |  FAX:      [phone]
Utrecht University                            |  Phone:    [phone]
Princetonplein 5                              |-------------------------------
3584 CC  Utrecht                              | "Truth is out of style"
The Netherlands                               | - MC 900 FT Jesus with DJ Zero
- ----------------------------------------------------------------------------



---------------------------

From: [e-mail] (Peter Sweeney)
Subject: TC5.0 and Colortoolbox
Date: 27 Feb 92 04:15:30 GMT
Organization: Miami University - Academic Computer Service

So, I'm using Think C 5.0.2 and I'd like to use Color
Quickdraw routines and such.  I'm specifically
hung up on using HSVColor.

What should I #include?  There is no ColorToolbox.h
with Think C 5.0.  Rats.  Where can I find HSVColor?

Thanks in advance.

any response is welcome.

Peter S.
[e-mail]



- -------------------------

From: [e-mail] (Brian Donnell)
Subject: Suggestion to the Developers of Think C
Date: 27 Feb 1992 22:37:08 GMT
Organization: NASA/JSC

I am posting this suggestion for Think C for general perusal rather than
sending it directly to Symantec so that other Think C users can add their
two cents worth.  The voice of many users will have more impact.

I think Think (:-)) C is one of the better programming environnments available
on the market today.  With each release have come more improvements.  There
are still things lacking (like C++ 2.1 conformance), but I think the largest
lacking feature is Think C's failure to report many types of errors/
bad coding styles.  I would like to see Think C create a listing of warnings
simliar to other compilers that includes things such as: unused variables,
suspicious typecasts, using = where it looks like == should be used, and
other things that are technically correct but may not be what the programmer
truly intended.

I would also like Think C to get way from this 'stop on the first error'
nonsense.  Write it all out to a log file - so that I can leave a long
compile unattended w/o being 99.999% sure that there will be no errors.

What does everyone else think?
Symantec, are you listening?

Brian Donnell
NASA/JSC



- -------------------------

From: [e-mail] (Paul Lucas)
Subject:  Suggestion to the Developers of Think C
Organization: University of Illinois at Urbana-Champaign
Date: Fri, 28 Feb 1992 01:32:10 GMT

In <[e-mail]> [e-mail] (Brian Donnell) writes:

>I am posting this suggestion for Think C for general perusal rather than
>sending it directly to Symantec so that other Think C users can add their
>two cents worth.  The voice of many users will have more impact.

>I think Think (:-)) C is one of the better programming environnments available
>on the market today.  With each release have come more improvements.  There
>are still things lacking (like C++ 2.1 conformance), but I think the largest
>lacking feature is Think C's failure to report many types of errors/
>bad coding styles.  I would like to see Think C create a listing of warnings
>simliar to other compilers that includes things such as: unused variables,
>suspicious typecasts, using = where it looks like == should be used, and
>other things that are technically correct but may not be what the programmer
>truly intended.

>I would also like Think C to get way from this 'stop on the first error'
>nonsense.  Write it all out to a log file - so that I can leave a long
>compile unattended w/o being 99.999% sure that there will be no errors.

>What does everyone else think?
>Symantec, are you listening?

    Think C is not C++ as I'm sure we all know; but, I too would
    like it to be.  (Why stop at C++ 2.1?  Go to 3.0.)  The world,
    or at least the Macintosh world, is going C++, especially with
    the rewrite of MacApp.  The division between Think and MPW is
    widening.  Also, once you learn C++, you can never go back to
    anything less, i.e., learn all the things you _can't_ do in
    Think C.

    Since they now own the Zortech compiler, it should be easy to
    fold it into the Think environment (which is a lot friendlier
    than MPW, not to mention _lot's_ more inexpensive--MPW C++
    withtout MacApp is $600).

    The upgrade price for 4.0 to 5.0 is too high (~$95); I'm not
    going to upgrade again until Think C++ arrives, if ever.  (Do
    you hear that, Symantec?  No more money until C++!)

    If they wan't to keep a market, they have to give it what it
    wants, not what they think is good for them.  The market wants
    C++; it wants it yesterday.
--
    - Paul J. Lucas                University of Illinois
      AT&T Bell Laboratories        at Urbana-Champaign
      Naperville, IL            [e-mail]



- -------------------------

From: [e-mail] (Gary P. Warren)
Subject:  Suggestion to the Developers of Think C
Date: 28 Feb 92 16:52:29 GMT
Organization: NASA Langley Research Center

In article <[e-mail]>, [e-mail] (Brian Donnell) writes:
>
> I am posting this suggestion for Think C for general perusal rather than
> sending it directly to Symantec so that other Think C users can add their
> two cents worth.  The voice of many users will have more impact.

I also like the enviroment of Think C as compared to MPW.  However, I would
like to see the linking of MPW .o files made easier and more reliable.
The oConv utility has too many restrictions.  I have been trying to link
Fortran code created with MacFortran II by Absoft with Think C.  This has
not been very productive.  It is quite easy to do on the unix side (Cray, DEC,
Sun, etc.) but the Think C enviroment is much nicer to program with.



- -------------------------

From: [e-mail] (Alan D.)
Subject:  Suggestion to the Developers of Think C
Organization: As little as possible
Date: Fri, 28 Feb 1992 18:52:41 GMT

[e-mail] (Paul Lucas) writes:
>In <[e-mail]> [e-mail] (Brian Donnell) writes:

>>I think Think (:-)) C is one of the better programming environnments available
>>on the market today.  With each release have come more improvements.  There
>>are still things lacking (like C++ 2.1 conformance), but I think the largest
>>lacking feature is Think C's failure to report many types of errors/
>>bad coding styles.  I would like to see Think C create a listing of warnings
>>simliar to other compilers that includes things such as: unused variables,
>>suspicious typecasts, using = where it looks like == should be used, and
>>other things that are technically correct but may not be what the programmer
>>truly intended.

I agree that putting "lint" capabilities into Think C (as they did
with Disassembly in 5.0) would be a great feature...  Even if they
didn't include the capability in the environment, having a separate
program which would handle lint would be great.  (If someone can point
me to the source, I _might_ be able to port it...)

>>I would also like Think C to get way from this 'stop on the first error'
>>nonsense.  Write it all out to a log file - so that I can leave a long
>>compile unattended w/o being 99.999% sure that there will be no errors.

I agree with this as well, but with a Lint feature, it would not be a
requirement.

>Since they now own the Zortech compiler, it should be easy to
>fold it into the Think environment (which is a lot friendlier
>than MPW, not to mention _lot's_ more inexpensive--MPW C++
>withtout MacApp is $600).

... We hope.  I'm all for a Think C++.  I would love to see it.  I
might even feel good about spending another $50-100 for an upgrade,
except that I just upgraded to 5.0....
[...]

One other suggestion I have for Symantec is that they support the
extended keyboard's special keys a little better.  Page up, down,
home, etc. should move the cursor, not just the window...  Maybe
having a key which would return to the last 'editing point' would make
them feel better about changing this, but I think this would be an
important change.

My thanks go out to Phil Shapiro and Rich Siegel for supporting
Symantec's products on the net.

    -=Alan
    [e-mail]



- -------------------------

From: [e-mail] (Donald T. Major)
Subject:  Suggestion to the Developers of Think C
Date: 28 Feb 92 18:54:08 GMT
Organization: SAS Institute Inc.

In article <[e-mail]>, [e-mail] (Brian Donnell) writes:
[stuff deleted]
|> I would also like Think C to get way from this 'stop on the first error'
|> nonsense.  Write it all out to a log file - so that I can leave a long
|> compile unattended w/o being 99.999% sure that there will be no errors.

No, no, no (:-))!  I actually LIKE the way the compiler works, as far
as stopping on the errors, and I'll put up with damn near anything as
long as the compile-link phase is as fast as it is with Think C.  If I
wanted a batch compiler, I'd have bought MPW C.  Interaction is one of
the key features of the Think languages (I have both), so I say leave
it alone!

Now I _would_ like to see a Think C++...:-)

My $0.02 worth...:-)

                                                 ..
                                                dtm

--
Donald Major       SAS Institute Inc.  "Cicely, let's fling something!"
[e-mail] SAS Campus Drive                 - Northern Exposure
[phone]     Cary, NC 27513-2414



- -------------------------

From: [e-mail] (Dean NEWTON)
Subject:  Suggestion to the Developers of Think C
Organization: SOCS, McGill University, Montreal, Canada
Date: Fri, 28 Feb 1992 19:45:07 GMT

In article <[e-mail]> [e-mail] (Brian Donnell) writes:
>
>I think Think (:-)) C is one of the better programming environnments available
>on the market today.

Still can't hold a candle to GNU emacs, IMHO.

>I would also like Think C to get way from this 'stop on the first error'
>nonsense.  Write it all out to a log file - so that I can leave a long
>compile unattended w/o being 99.999% sure that there will be no errors.

Amen.

>What does everyone else think?

A couple of things I find sorely lacking:

-- built-in yacc, lex, awk, sed
-- a Makefile facility (eg. for running awk and sed scripts on files before
   compilation)
-- a programmable editor (emacs just ruins you for life!)
-- generic functions (if C++ is not going to be available soon)

Kaveh Kardan
(posting from a friend's account)




- -------------------------

From: [e-mail] (Bernie Bernstein)
Subject:  Suggestion to the Developers of Think C
Date: 28 Feb 92 21:26:14 GMT
Organization: University of Colorado, Boulder

In article <[e-mail]> [e-mail] writes:
>
>One other suggestion I have for Symantec is that they support the
>extended keyboard's special keys a little better.  Page up, down,
>home, etc. should move the cursor, not just the window...  Maybe
>having a key which would return to the last 'editing point' would make
>them feel better about changing this, but I think this would be an
>important change.
>

We all have ideas of what a good editor should do. Some good editors
exist, but I don't use them because they are not integrated with the
Think C environment.  I believe the Think C editor should have hooks
so that we can write our own macros, or better yet, allow developers
to hook their own editors in so that the edit/compile/run cycle is
just as easy regardless of whose editor is being used.

Of course, as a poor grad student, I'd prefer if the great features
are included with the environment that I already bought, but no matter
how many features are there, someone will always want more.

>My thanks go out to Phil Shapiro and Rich Siegel for supporting
>Symantec's products on the net.
>

I second the appreciation of the Think groups help here.


--
      o,  ,,   ,      | Bernie Bernstein                      | ,    ,,
      L>O/  \,/ \    ,| University of Colorado at boulder     |/ \,,/  \
     O./  '  / . `, / | office: [phone]                |     / ` \  ,.
    ,/   /  ,      '  | email: [e-mail]        | /        ''  \



- -------------------------

From: [e-mail] (Pete Resnick)
Subject:  Suggestion to the Developers of Think C
Date: 28 Feb 92 22:15:46 GMT
Organization: University of Illinois at Urbana

[e-mail] (Alan D.) writes:

>One other suggestion I have for Symantec is that they support the
>extended keyboard's special keys a little better.  Page up, down,
>home, etc. should move the cursor, not just the window...

Ain't been reading your Inside Mac, have ya' buddy? :-)

Inside Mac IV (?) specifically says that page up, page down, home
and end *must only* move the window, not the cursor. Those keys
are basically keyboard equivalents for clicking in the scrollbar.

Maybe adding command-page up or command-page down would be nice.

pr
--
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]



- -------------------------

From: [e-mail] (Vince Vann)
Subject:  Suggestion to the Developers of Think C
Date: 28 Feb 92 22:17:28 GMT
Organization: University of Miami Medical School

[e-mail] (Brian Donnell) writes:

>I am posting this suggestion for Think C for general perusal rather than
>sending it directly to Symantec so that other Think C users can add their
>two cents worth.  The voice of many users will have more impact.

>I would also like Think C to get way from this 'stop on the first error'
>nonsense.  Write it all out to a log file - so that I can leave a long
>compile unattended w/o being 99.999% sure that there will be no errors.

There should be an option setting to make compilation either 1) stop
automatically at the first error encountered, or 2) compile fully and
display an error log.

 /===================================\ /================================\
|  Vincent R. Vann                    |  "Great spirits have always      |
|  Univ. of Miami School of Medicine  |   encounterd violent opposition  |
|  Miami, Florida                     |   from mediocre minds..."        |
|                                     |                                  |
|     [e-mail]       |       -- Albert Einstein         |
 \===================================/ \================================/



- -------------------------

From: [e-mail] (David Ascher)
Subject:  Suggestion to the Developers of Think C
Date: 29 Feb 92 00:35:38 GMT
Organization: Brown University


Actually, i don't mind stop on error.

BUT:  I'd love a _warning_ generator.  And that could write to a file.
Along with a configuration of what warnings are, like the Code
Preference dialog box -- I don't usually want prototypes on (makes
callbacks harder), but I like to know that sometimes.  Similarly for
strange casts -- I'd like to know about them.

(that and fixing the bugs in Think Reference)

--da
--
david ascher  [e-mail]   401/863-7324
brown university computing and information services



- -------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject:  Suggestion to the Developers of Think C
Date: 28 Feb 92 23:07:42 GMT
Organization: Kalamazoo College

[e-mail] (Brian Donnell) writes:
>
>I would like to see Think C create a listing of warnings
>simliar to other compilers that includes things such as: unused variables,
>suspicious typecasts, using = where it looks like == should be used, and
>other things that are technically correct but may not be what the programmer
>truly intended.

Yes, this would be very nice, especially "= instead of ==" (the typo
that bites everyone once in a while).

>I would also like Think C to get way from this 'stop on the first error'
>nonsense.

This I don't mind as much.  I'm pretty sure they did it that way to
speed compiling.  They've probably optimized the hell out of the
compilation routines, and adding error-recovery might require a full
rewrite.  The fast turnaround time encourages write-and-go coding, which
I (and probably many others) prefer.

I'd rather have snappy compiles that force me to watch my typing than
hour-long, memory-hogging compiles that give me an error log.
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.



- -------------------------

From: [e-mail] (David Spencer)
Subject:  Suggestion to the Developers of Think C
Date: 28 Feb 92 23:48:14 GMT
Organization: PANIX Public Access Unix, NYC

My Think C improvements:

The ability to compile gnu or public domain (or home-brew) tools and
run them inside TC by selecting them from a user-configurable menu.
Selecting the menu item calls a user-creatable commando(TM) that
constructs the argv's and passes them to the tool. One can't do heavy
lifting without tools; why do we have to get MPW to get tools?

grep that runs on non-project files. File selection with wildcards.

The complete lack of user-configurability in the editor is a real
pain. A _programming environment_ without a macro facility? Gimme a break!

A/UX support would be nice (or at least a debugger that would run
under aux). Casting the runes with gdb when all I want to do is step
through the execution with the variables in a side window....

David Spencer
[e-mail]



- -------------------------

From: [e-mail] (Zach Kessin)
Subject:  Suggestion to the Developers of Think C
Date: 29 Feb 92 00:51:15 GMT
Organization: Brandeis University

[e-mail] (Bernie Bernstein) writes:

>In article <[e-mail]> [e-mail] writes:
>>
>>One other suggestion I have for Symantec is that they support the
>>extended keyboard's special keys a little better.  Page up, down,
>>home, etc. should move the cursor, not just the window...  Maybe
>>having a key which would return to the last 'editing point' would make
>>them feel better about changing this, but I think this would be an
>>important change.
>>

YES PLEASE!

>We all have ideas of what a good editor should do. Some good editors
>exist, but I don't use them because they are not integrated with the
>Think C environment.  I believe the Think C editor should have hooks
>so that we can write our own macros, or better yet, allow developers
>to hook their own editors in so that the edit/compile/run cycle is
>just as easy regardless of whose editor is being used.

How about using apple-events to control the environment, you could use
whatever editor you wanted, and have it tell think C to compile or
link bring up the class browser. Also you could have think Pascal use
the same apple-events so that you could use one editor with both.

>Of course, as a poor grad student, I'd prefer if the great features
>are included with the environment that I already bought, but no matter
>how many features are there, someone will always want more.

>>My thanks go out to Phil Shapiro and Rich Siegel for supporting
>>Symantec's products on the net.
>>
YES THANKS to Phil and Rich!!!!!!

>I second the appreciation of the Think groups help here.

>--
>      o,  ,,   ,      | Bernie Bernstein                      | ,    ,,
>      L>O/  \,/ \    ,| University of Colorado at boulder     |/ \,,/  \
>     O./  '  / . `, / | office: [phone]                |     / ` \  ,.
>    ,/   /  ,      '  | email: [e-mail]        | /        ''  \

Other Idea's: make the debugger more like think Pascal,  Lightsbug is
Wonderful! It is nice to be able to do all of the thinghs that
pascal's debuger can do, ie: watchpoints, looking at the heap, etc.

Also it helps to be able to see many breakpoints at one time.

C++ would be real nice!!!

--Zach

   Zachary Kessin                / --------------------------------+
 [e-mail]  / real.world: I don't think the    |
 Kessin@brandeis (BITNET)      /   news server gets that group!    |
 [phone]                /____________________________________|



- -------------------------

From: [e-mail] (Bob Finch)
Subject:  Suggestion to the Developers of Think C
Date: 29 Feb 92 10:32:49 GMT
Organization: WA7IPX

In <[e-mail]> [e-mail] (Brian Donnell) writes:

>I am posting this suggestion for Think C for general perusal rather than
>sending it directly to Symantec so that other Think C users can add their
>two cents worth.  The voice of many users will have more impact.

There are several features I'd like to see in the Think C debugger:

1. The ability to display local variables that are not in the top
   stack frame.

2. The scoping rules in data window expressions should be relaxed so
   that statics, typedefs, etc. can be used anywhere.  Since this may
   introduce ambiguities, there should be a way to specify the one you
   want.

3. Expressions with side effects.  I'd especially like to call
   functions and procedures.

--

    Bob Finch
    [e-mail]
    [e-mail]



- -------------------------

From: [e-mail] (Matthias Ulrich Neeracher)
Subject:  Suggestion to the Developers of Think C
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: 29 Feb 92 17:15:26

In article <[e-mail]> [e-mail] (Kaveh Kardan) writes:
>In article <[e-mail]> [e-mail] (Brian Donnell) writes:
>>
>>I think Think (:-)) C is one of the better programming environnments available
>>on the market today.
>
>Still can't hold a candle to GNU emacs, IMHO.
>
>>I would also like Think C to get way from this 'stop on the first error'
>>nonsense.  Write it all out to a log file - so that I can leave a long
>>compile unattended w/o being 99.999% sure that there will be no errors.
>
>Amen.
>
>>What does everyone else think?
>
>A couple of things I find sorely lacking:
>
>-- built-in yacc, lex, awk, sed
>-- a Makefile facility (eg. for running awk and sed scripts on files before
>   compilation)
>-- a programmable editor (emacs just ruins you for life!)
>-- generic functions (if C++ is not going to be available soon)

Sounds like you're describing MPW :-) The major qualities of TC seem to be that
it's a lean and mean C compiler. You can't just go on adding features to such a
development system without sacrificing the original qualities.

IMHO, if you can't live with the limitations of an integrated development
environment like Think C, use MPW. As many languages as you want (I'm using
Pascal, C, C++, Assembler, gawk and perl regularly and would be *very* unhappy
to be limited to C--).

Matthias

- ---
Matthias Neeracher                                      [e-mail]
 `We say "gestalt" when things combine to act in ways we can't explain'
                             -- Marvin Minsky, _The Society Of Mind_



- -------------------------

From: [e-mail] (Jim Russell)
Subject: Suggestion to the Developers of Think C
Date: 28 Feb 92 23:58:39 GMT


 BD> I would also like Think C to get way from this 'stop on the first error'
 BD> nonsense.  Write it all out to a log file - so that I can leave a long
 BD> compile unattended w/o being 99.999% sure that there will be no errors.

I treat compiling as part of my debugging process, so I'm not really bothered by having to fix one error at a time. (At least not like I would have been in the old batch world.) There is at least one advantage - you don't waste time pondering bunch of "false alarms"; propogated errors caused only by the first one reported.  Indeed, what's a poor compiler to do trying to plug on past the first error which left, for example, a function or variable undefined or the first part of a control structure inco




- -------------------------

From: [e-mail] (Stephen Kurtzman)
Subject:  Suggestion to the Developers of Think C
Date: 29 Feb 1992 09:49:35 -0800
Organization: University of Southern California, Los Angeles, CA

In article <[e-mail]>
[e-mail] (Jim Russell) writes:

BD> I would also like Think C to get way from this 'stop on the first error'
BD> nonsense.  Write it all out to a log file - so that I can leave a long
BD> compile unattended w/o being 99.999% sure that there will be no errors.

>I treat compiling as part of my debugging process, so I'm not really
>bothered by having to fix one error at a time. (At least not like I
>would have been in the old batch world.) There is at least one
>advantage - you don't waste time pondering bunch of "false alarms";
>propogated errors caused only by the first one reported.

I'm not sure this is much of a problem. It has been easy to identify
propagated errors with every compiler I've ever worked with. It is only
the first week of working with a new compiler that slows you down.
After that, it is much faster to be able to correct more than one error
per compile. It would be easy for Symantec to make stopping at the first
error an option if they had the ability to continue on. Then everyone
would be satisfied. (BTW, I agree that it is a great product. This
type of complaint is really nitpicking.)
--

Stephen Kurtzman             | "where desire writhed there stands a stone;
[e-mail]      |  the change was sudden and complete"
                             |                              -- Maggie Roche



- -------------------------

From: [e-mail] (Alen Shapiro)
Subject:  Suggestion to the Developers of Think C
Date: 29 Feb 92 18:03:46 GMT
Organization: Crash TimeSharing, El Cajon, CA

In <[e-mail]> [e-mail] (Bob Finch) writes:


>1. The ability to display local variables that are not in the top
>   stack frame.

This is on the top of my list.

>2. The scoping rules in data window expressions should be relaxed so
>   that statics, typedefs, etc. can be used anywhere.  Since this may
>   introduce ambiguities, there should be a way to specify the one you
>   want.

>3. Expressions with side effects.  I'd especially like to call
>   functions and procedures.

These would be great too.

If we can't hook our own editors in, then
how about allowing the window to follow the cursor horizontally
as well as vertically. When I do a search on a long line, I have to
manually scroll the wondow horizontally to locate the cursor...kinda
breaks the find/replace pattern.

How about marking each function
in a file automatically - or better still have a "project-title-bar-modifier-
click" that displays a selectable list of all functions in the project
to allow immediate cursor positioning at any function. Cmarker is close
but not close enough to "ctags" functionality.

I use a DOS compiler (yuch) to give me lint-like messages about unused
variables and assignment badnesses. I should not have to (of course it would
be nice if I did not write the bad code in the first place (I'm working
on that problem)).

Nice product Symantec...please make it better

--alen
[e-mail]

>    Bob Finch
>    [e-mail]
>    [e-mail]



- -------------------------

From: [e-mail] (Jeffrey Verdegan)
Subject:  Suggestion to the Developers of Think C
Date: 29 Feb 92 21:06:09 GMT
Organization: Computer Aided Engineering, Univ. of Wisconsin-Madison

In article <[e-mail]> [e-mail] (Brian Donnell) writes:
>bad coding styles.  I would like to see Think C create a listing of warnings
>
>I would also like Think C to get way from this 'stop on the first error'
>nonsense.  Write it all out to a log file - so that I can leave a long
>compile unattended w/o being 99.999% sure that there will be no errors.
>
>What does everyone else think?

I agree 10^6% !!!!

>Symantec, are you listening?
>

Is there some other way to get their attention besides wasting lots of
bandwidth (like I'm doing =:-)) to send a whole boatload of "yes" votes to the
above suggestions?  On the other hand, I'm sure there are other similar issues
that will come up as a response to this.


Jeff


- --------

Jeff Verdegan
University of Wisconsin-Madison
Computer-Aided Engineering Center
[e-mail]
[phone]


P.S.  In case I wasn't clear above, warnings of unused variables would be
*extremely* useful, as would the ability to get an "all at once" list of errors!



---------------------------

End of C.S.M.P. Digest
**********************